This invention relates to a method of indicating the content of a message element, such as indicating a dual transfer mode handover command in an existing message, in particular to provide improved indication of dual transfer mode (DTM) handover command for general packet radio service (GPRS) enhanced data rates for global system for mobile communication (GSM) evolution (EDGE) DTM handover.
DTM handover is a recently developed procedure designed to allow a mobile phone, which currently has allocated dedicated, i.e. circuit-switched (CS), resources and also allocated packet switched (PS) resources, to be handed over to a new cell. The procedure makes use of existing procedures for handover of the CS resources and the PS resources in parallel.
As illustrated in FIGS. 1 and 2, a source base station subsystem (BSS) 1 initiates the handover by sending two requests, one relating to the circuit switched resources, which is sent to a CS core network 3 and the other relating to the PS resources, sent to a PS core network 7. These requests are forwarded through each respective core network to a target BSS 5.
Included in the requests are indications that the requests form part of a DTM handover procedure, so that the target BSS 5 knows, on receiving the first request, to wait for the second request before allocating resources.
Normally, the target BSS allocates both PS and CS resources and constructs a 'DTM Handover Command’ message, which is sent back to the source BSS 1 via both core networks 3, 7, so that the source BSS receives two copies of the message, encapsulated within the appropriate message.
However, if there is a problem such as delay or loss in the core network meaning only one request is received, or there is a lack of resources available, then the target BSS 5 may end up allocating only resources in one domain, either PS or CS. If only CS resources are allocated, the target BSS constructs a ‘Handover Command’ message, and sends that back to the source BSS 1 via the CS core network 3.
In order to ensure there is no impact on the core network nodes, the mobile switching centre (MSC) and the serving GPRS support node (SGSN), the existing message flows for CS and PS Handover are used within the respective domains. Normally, new information elements could easily be added to an existing message, identified by a information element identifier (IEI). However, in the case of CS Handover, some existing information elements (including specifically that which encapsulates the ‘Handover Command’ message which is to be sent over the air to the mobile station) are handled in a very specific way by the core network—specifically, these information elements are not examined by the core network, but are passed ‘transparently’ from the target BSS to the source BSS. This same treatment by the core network is required for the corresponding ‘DTM Handover Command’ message used in DTM Handover. It is therefore desired that, to minimize the changes needed to the core network, the message which is sent to the mobile station in the case of DTM Handover is contained within an IE which is identified by the same IEI as that which is used to carry the air interface “Handover Command” used in legacy CS handovers.
However, at the source BSS, it may be very difficult, if not impossible, to determine whether the content of the IE relates to a CS handover or a DTM Handover, and therefore to distinguish between an acknowledgement message from the CS core network which contains a DTM Handover Command, and one which contains a (CS only) Handover Command. Since these messages are processed in very different ways, the source BSS needs to know which message is included in order for the handover to proceed.
In some circumstances it is possible for the source BSS to infer which message is included, e.g. in the successful case, if positive acknowledgements are received from both PS and CS domains, then these will both contain a DTM Handover Command. However, in cases where only one message, from the CS core network, is received by the source BSS 1, it is not possible to determine which type of message has been received. The one message may be from the case where a DTM Handover has resulted in a CS-only handover, and may not necessarily be a failure case.
It is also not possible to infer the content if a positive acknowledgement is received in the CS domain, and a negative acknowledgement is received in the PS domain, which indicates by a ‘cause’ value, that no resources were reserved by the target BSS in that domain. Other failure cases include where no PS message is received, or where the PS message indicates failure in the PS core network, but no solution to these problems has been proposed to date.